In the early 1990's, the commercial real estate finance industry was just beginning to recognize the potential of accessing capital markets through Commercial Mortgage Backed Securities (CMBS). Traditionally, commercial mortgages had been originated and held on balance sheets, with servicing provided by the originating mortgage banker or portfolio lender. Entities such as the Resolution Trust Corporation (RTC), for example, stimulated the CMBS industry by bundling and securitizing multiple performing commercial and multifamily loans. These transactions placed pressure on servicers to handle the change in volume and complexity.
Most commercial loan servicers employed residential asset/loan servicing systems that had been reprogrammed to accommodate the commercial market. Built on mid-range or mainframe platforms, however, these systems—although to a degree stable and reliable—were usually rigid and hard to modify or scale without enormous time and expense. Systems administration and maintenance costs, for example, as well as hardware capital expenditures, were substantial.
In mid-range or mainframe environments, information is housed and maintained at the server level, and therefore user workstations have limited flexibility. These platforms also require costly proprietary hardware and dedicated, specialized systems resources. A relatively minor change in functionality could require redeployment of the entire system. While being useful for a comparatively simpler, more standardized residential mortgage market, these platforms are less than ideal for the complexity of commercial loan servicing—and the rapidly evolving CMBS sector of the industry.
Technology providers then began developing client/server applications presented on the Windows® platform made universal by Microsoft Corporation, for example. Graphical User Interfaces (GUIs), or point-and-click screens, replaced the prior “green” screens of mid-range and mainframe computing environments, as technology providers worked to meet customer demand for user-friendly front-ends. In addition to a Windows-based environment, client/server systems offered users more flexibility, because individual copies of the software resided on each workstation. This made the systems easier to use, but the underlying technology remained difficult and costly to modify and maintain. With software at every desktop, however, administration costs escalated and performance declined as the user community grew. Modifying a client/server system was also generally a time-consuming and expensive endeavor.
By the mid-1990's, the CMBS market had taken hold and was growing rapidly. One study showed, for example, that CMBS issuance in the United States grew from less than $18 billion in 1995 to more than $77 billion in 1998—a four-year increase of more than 400 percent. Borrowers were attracted to the availability of high leverage at relatively low rates on a non-recourse basis, and investors, in turn, benefited from high risk-adjusted returns, diversity and liquidity. However, CMBS investors lacked the implicit agency assurance the residential mortgage-backed securities market enjoyed. There was no commercial equivalent to Fannie Mae or Freddie Mac, for example, to backstop the industry. Instead, CMBS issuers were able to sell non-investment grade bonds including the first-loss risk to high-yield investors. These B-piece investors had the ability to analyze and price the credit risk of the underlying mortgage collateral, and the capability to control the resolution of defaulted loans through special servicing. The industry relied on loan servicers to provide the information critical to supporting the ongoing surveillance of rating agencies and the risk management B-piece investors. The result has been improved liquidity for CMBS investments, and an active B-piece market.
CMBS servicers have worked to capture and report information demanded by rating agencies and investors. Faced with rapid industry growth, constantly shifting requirements, and limitations of existing technology, CMBS servicers have worked around their core systems to create custom system solutions. With multiple property types and complex loan structures common on CMBS issuance, these custom systems became the status quo for handling a broad range of operational activities and generating reports to rating agencies, trustees and investors. High monthly loan volumes, coupled with short turnarounds, however, strained the systems of servicers. In addition, adequate reporting standards did not exist.
The Commercial Mortgage Securities Association (CMSA®) then introduced a CMBS investor reporting package. The package provided servicers with common standards needed for investor reporting on CMBS transactions. Although CMBS servicers utilized capacity-limited systems and manual processes to capture the data and deliver the reports, the CMSA® package represented a step toward standardization. Some technology vendors have incorporated the CMSA® investor reporting standards into their software packages.
Typically, a commercial, loan servicer would license a core servicing system for loan administration, escrow administration, and payment processing, and then design internal systems to customize information for its CMBS portfolios. These internal systems were often built on a host of different platforms, however, that were difficult to integrate with each other or with the core servicing system. Data integrity across these multiple systems was an issue. What often resulted was an inefficient combination of systems, databases and manual processes.
A majority of servicers continue to struggle to meet CMBS requirements with such inefficient, counter-productive methods and systems. Servicers are subject to adverse fluctuations in the real estate economic environment. Systems currently in place—licensed or proprietary—may have been designed in the context of a strong market, for example, and may have little capacity to adapt to the specific servicing requirements in a down market. A rise in non-performing loans could have a dramatic impact on operations of a servicer, especially a servicer that uses limited-capacity side systems or manual processes to track scheduled versus actual loan balances and protective advances. Servicers using such systems and processes may transfer many loan administration activities to third-party special servicers. In addition, the inability to adapt to market changes could prove a substantial problem to such servicers. CMBS servicers therefore need to use a flexible infrastructure that can adapt to increased loan defaults and resultant special servicer interaction.
There is a widespread recognition that the CMBS servicing industry needs a technology boost. Empowering technologies such as browser-based applications and open relational databases, for example, have helped other industries to reduce costs, streamline operations and leverage information. Recognizing this, financial servicers have created certain web-based systems to service CMBS and have acquired mortgage technology products designed for use by the financial industry.
What follows is a description of certain existing technologies that may be applied to asset/loan servicing and CMBS servicing, in particular. Browser-based applications utilize a browser-server, where the system resides and all data is stored. Each workstation is equipped with a standard browser. These systems are typically hardware independent, allowing a company to choose commercially available workstations. Unlike mid-range, mainframe and client/server applications, browser-based systems are extendible to users located anywhere, at anytime, with maximum utilization and speed, thereby enabling a wide-area network. Familiar navigation functionality provides an Internet browser with the capacity to move readily through the system. Due to their highly robust and reliable operation environments, browser-based applications can accommodate user and data growth with relatively little impact on performance. Changes to the system can be substantially seamless and automatic, taking place at the server level. Users can exchange and integrate internal and external information from other computer applications and languages (including, for example, e-mail and Microsoft® Office), facilitating communication, reducing paperwork and laying the groundwork for e-commerce.
Open relational databases allow users to establish relationships across the database for a high degree of flexibility without sacrificing ease of use. These databases can be integrated with almost all computer platforms and languages. In a highly normalized relational database, changes in business requirements have relatively little or no impact on existing software. A relational database also provides facilities for many different programs to be used as reporting or analytical tools. Sophisticated, ad-hoc queries can be made across any data element. This flexibility can be useful, for example, in handling the dynamic, complex deal structures of the CMBS market.
A business rule is a statement that defines or constrains some aspect of a business. It is intended to assert business structure or to control or influence the behavior of a business. No universally applied business rule standards currently exist to define various phases of commercial mortgage securitization.
Rules-based functionality can be configured to allow servicers to establish business rules and automate manual processes associated with loan processing. With a rules-based system, servicers can manage their portfolios by exception, specifying workflows, exception conditions, and notifications of anomalies at both the server and user levels.
Object-oriented, multi-tier architecture enables long-term reuse of system code components, regardless of the user interface, for rapid application development and functionality changes. In addition to superior modeling of business requirements, this type of system scales as data and users grow, while maintaining relatively high availability and performance.
The present inventors believe that the application of these emerging technologies could dramatically improve asset/loan-servicing environments including, for example, the CMBS environment. Servicers could reduce their hardware and software expenses, system administration and, maintenance costs and user training. Rules-based functionality and management by exception could reduce headcount per loan, enabling personnel to focus on higher value-added activities. By using the Internet to transmit data, the servicer could receive third-party information, such as property operating statements, rent rolls, site inspections, appraisals and the like in an electronic form, which can be directly imported into the servicing system. Special servicers could directly access the system to review and update loan information and communicate with the servicer.
Sub-servicing may also change with the ability to distribute functions through a shared-servicing relationship. The sub-servicer could retain the borrower relationship and customer service functions, while the master servicer could provide the payment processing, loan administration and investor reporting functions. Redundancies and overall costs could be reduced, increasing the value of the servicing rights of both the sub-servicer and master servicer. CMBS investor reporting, including on-line facilities, could be fully automated with improved data integrity.
Another benefit of these advancements is that they need not be reserved only for relatively large servicers that can afford to acquire or license new technology. Ideally suited to the Application Service Provider (ASP) environment, these systems could let small-size and medium-size servicers or sub-servicers affordably access and exploit technology. Improved methods and systems are needed for servicers to have the opportunity to modify existing servicing operations to reduce costs, enhance productivity and better manage their loans.
Database models of existing systems usually account for the processing of assets under the basis of a loan but do not model the business objects. Conventional models generally take the approach that this is a loan system and do not handle ownership of the assets being processed. In addition, existing databases do not account for functions that must be performed with respect to providing reports to borrowers, as well as information relating to who owns the asset/loan for the reporting relationship. Instead, conventional systems usually must provide multiple side systems with multiple data models in order to do everything necessary for processing and reporting asset/loan information.
The present inventors have concluded that what are needed are systems and methods designed to model the life of a loan/asset and to provide an object/data model to handle the origination of a loan through disposition of the loan. The database model should handle the life of the loan and/or the life of the asset, as well as substantially all of the accounting functions the owner would use to manage the loan.
The present inventors further conclude that what are needed are systems and methods that provide a comprehensive relational/object model that captures many or all complex data relationships for multiple and complex asset classes. The asset classes may include, for example, both residential and commercial real estate loans, consumer loans, and real estate owned. The model should capture both key information for the processing and management of such assets and should also include the complex ownership relationships for such assets. The model should further include a comprehensive rules engine to calculate, for example, complex fees such as distributions of cash received by investors.